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ABSTRACT 


This paper is intended for consideration by developers of small shuttle payloads, including integration and test 
(I&T) managers, project managers, and system engineers. Recommended approaches for small space shuttle 
payload I&T are presented. Examples and lessons learned are provided based on the extensive history of NASA’s 
Hitchhiker project. 

All aspects of I&T are presented, including: 

• I&T team responsibilities, coordination, and communication 

• Flight hardware handling practices 

• Documentation and configuration management 

• I&T considerations for payload development 

• I&T at the development facility 

• Prelaunch operations, transfer, orbiter integration and interface testing 

• Postflight operations. 

This paper should be of special interest to those payload projects that have small budgets and few resources: 
that is, the truly “faster, cheaper, better” projects. All shuttle small payload I&T managers are strongly encouraged 
to apply these guidelines during I&T planning and ground operations to take full advantage of today’s limited 
resources and to help ensure mission success. 
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1. INTRODUCTION 

1.1 Overview and Scope 

Integration and test (I&T) of space shuttle small 
payloads, such as those historically designated as “Class 
D,” is typically accomplished on a much smaller scale 
than most other human-rated space projects. The 
streamlined nature of these projects enables a level of 
flexibility and responsiveness not possible with larger 
projects. Smaller team size, on the order of a dozen 
total, means each individual has a more significant role 
in the development, integration, and test of the 
spacecraft. 

Presented here are guidelines and recommendations for 
shuttle small payload I&T based, in part, on lessons 
learned over the 1 8-year history of Hitchhiker payloads. 
Hitchhikers are one of several “in-house” projects of 
the Shuttle Small Payloads Project Office (SSPPO) at 
NASA’s Goddard Space Flight Center (GSFC). 

After 29 missions involving over 60 separate 
instruments, the Hitchhiker project team has gained a 
wealth of experience in integrating and testing shuttle 
payloads with a core cadre of I&T personnel. Although 
many details and examples presented here are based 
on the Hitchhiker program, the basic approaches are 
directly transferable to any small payload project. 
Current or prospective payload developers, and in 
particular I&T managers, are encouraged to consider 
and apply these guidelines during I&T planning and 
ground operations. 

In addition, I&T suggestions for shuttle small payload 
customers can be found in [1], An example of customer 
accommodations and services provided by the 
Hitchhiker carrier, as well as additional details regarding 
shuttle I&T, is found in [2]. Additional lessons learned 
can be found in [3]. 

The focus of this paper is on payload-level integration 
and test. Therefore, details regarding design and 
qualification testing of individual components and 
subsystems are not presented. 

1.2 Definitions 

Carrier: The payload infrastructure that acts as a 
mechanical and electrical interface between the payload 
customer(s) and the orbiter. The carrier not only 
supports the customer hardware mechanically, but may 
also provide such services as power, command and data 


handling (C&DH), and thermal control. For example, 
carriers for Hitchhiker payloads are mounted in the 
payload bay, either on the side or cross-bay using 
Mission-Peculiar Equipment Support Structure 
(MPESS) “bridges.” 

Customer: The user (principal investigator or other 
instrument representative) of the payload c airier who 
develops and delivers the instrument to the carrier 
organization. Often, “customer” is used synonymously 
to refer to the instrument hardware itself (as in 
“customer interfaces”). At Kennedy Space Center 
(KSC), however, the term “payload customer” typically 
refers to the overall integrated payload organization. 

Experiment: The scientific research, technology 
demonstration, or other operation conducted during the 
mission using the instrument. 

Instrument: The customer hardware subassembly, one 
or more of which are integrated onto the payload carrier. 

Integration and Test: The process by which a payload 
is developed, assembled, and tested for flight. This 
includes I&T at the payload development facility, as 
well as that at the launch site (usually KSC). 

I&T Manager: The person usually responsible for 
coordinating the I&T team, and for directing payload 
I&T from development through postflight deintegration. 

I&T Team: A multidisciplinary group of engineers and 
technicians responsible for developing, integrating, and 
testing a payload to prepare it for flight. Areas of 
expertise may include such disciplines as mechanical, 
electrical, and thermal engineering, as well as ground 
data systems. 

Payload: The integrated spacecraft assembly composed 
of a flight carrier supporting one or more instruments. 
The term is also used here to refer to the payload 
development organization responsible for delivering the 
integrated payload to KSC. 

Task Leader: The member of the I&T team who is 
responsible for directing a particular operation. This 
person may be an engineer, technician, or other 
individual who is intimately familiar with the procedure, 
and who is fully qualified to lead the operation. 
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2. I&T MISCELLANEOUS 

2.1 The I&T Team 

2.1.1 Team Responsibilities 

The I&T team for a given payload is generally 
composed of engineers and technicians representing a 
range of disciplines, such as mechanical, electrical, and 
thermal engineering. For some autonomous free-fliers 
(such as Spartans), personnel supporting disciplines 
such as attitude control and propulsion may also be 
involved. 

Prior to the start of I&T, all personnel must understand 
their assigned responsibilities. Lead engineers must 
always be kept apprised of all significant developments 
and meetings, as they are the primary points of contact 
for their areas of expertise. 

During I&T, personnel supporting a particular operation 
are responsible for ensuring that all necessary 
equipment is on hand, calibrated (if required), and 
properly configured. They should also be “on station” 
prior to the start of a procedure and be present (or at 
least on call) until the operation is completed. This could 
be important if, for example, troubleshooting is 
necessary that requires the support of specific 
individuals. 

2.1.2 I&T Manager Responsibilities 

The following is a summary of responsibilities that fall 
under the purview of the I&T manager for shuttle small 
payloads: 

• Leads the I&T team, including engineers, 
technicians, and customers 

• Serves as the primary point of contact regarding 
integrated payload I&T issues 

• Coordinates I&T operations, including resources, 
facilities and support services 

• Works with project management to prioritize and 
resolve conflicts regarding schedule, support and 
resources 

• Develops integrated payload I&T plan and 
procedures 

• Develops and maintains schedules for integrated 
payload I&T at the development facility and launch 
site 


• Informs the I&T team, project management, and 
individual instrument customers regarding I&T 
status and issues 

• Provides input to payload design issues that may 
affect I&T 

• Provides inputs to shuttle program documentation, 
such as the Payload Integration Plan (PIP), Interface 
Control Document (ICD), and safety data packages 

• Serves as primary point of contact with KSC for 
requirements, scheduling, procedures, and operations 
at the launch site 

• Develops “lessons learned” following each mission, 
as applicable. 

Ultimately, the I&T manager’s primary job is to 
facilitate the I&T of the payload in as safe and timely a 
manner as possible. 

2.2 I&T Coordination 
2.2.1 Meetings 

Regular I&T meetings arc suggested to keep the I&T 
team informed. The frequency of I&T team meetings 
depends on many factors: 

• The amount of time until start of I&T. That is, I&T 
meetings should be more frequent (e.g., once a week) 
as the start of I&T becomes imminent. 

• The criticality of the operations at hand. For example, 
hazardous operations usually require more intense 
team coordination than those that are nonhazardous. 

• The level of I&T activity for the payload itself. That 
is, when the team is involved in an intense level of 
activity (e.g., multiday operations), daily I&T team 
meetings may be warranted. These can be as simple 
as stand-up status meetings in an off-line lab or “on 
the floor.” 

• The frequency of project-level meetings. This will 
be, in general, inversely proportional to the frequency 
of I&T meetings. 

• The level of activity within the project as a whole, 
that is, the amount of time which the members of 
the I&T team have available to attend meetings while 
supporting other activities. 
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It may also be desirable, if time allows, to organize an 
“I&T retreat” for the team early during the payload 
design phase. A retreat provides an informal atmosphere 
in which the team can brainstorm regarding I&T flow 
and any design issues that may affect I&T. Success of 
such a retreat requires that the I&T team, especially 
the lead engineers, commit themselves to attend without 
interruptions. A meeting location away from team 
members’ offices usually helps facilitate uninterrupted 
participation. 

2.2.2 Schedules 

An I&T schedule is developed based on the KSC 
delivery and launch schedules, on inputs from the entire 
team and the customers, and on past experience. The 
schedule should be realistic: not overly ambitious, yet 
not overly conservative. In addition, some contingency 
in the schedule is usually prudent to allow for any 
unanticipated delays and problems. 

For example, support and deliverables are not always 
provided in time to meet the established schedule. 
Delays may be caused by a variety of factors, including 
long lead-time component deliveries, test failures, and 
design enhancements. In these situations, the I&T 
manager can consider several options: step up the effort 
(e.g., via overtime or more people), revise the schedule 
to accommodate the delays, or recommend some 
redesign in order to maintain the schedule. In any case, 
everyone involved with the payload I&T process must 
understand the importance of maintaining the schedule 
in order to ultimately meet the launch date. 

Use of Performance Evaluation Review Technique 
(PERT) charts is sometimes helpful in the early planning 
stages to help identify I&T flow. Maintaining the 
accuracy of large PERTs over time is, however, 
generally manpower intensive, particularly for smaller 
projects with limited resources. More basic scheduling 
tools are recommended for frequent tracking of I&T, 
such as one-page “Gaants” to highlight major I&T 
milestones. In the case of KSC I&T, which tends to be 
a short-duration, intense level of activity, a daily line- 
by-line summary of operations may be useful. 
Ultimately, the I&T manager should utilize the 
scheduling tool that he or she finds most effective. 

Ideally, project management should be provided an 
advance copy of the I&T schedule for review prior to 
general distribution. Schedules should be distributed 


in whatever form is most convenient for the team, such 
as electronic distribution or website posting. 

The I&T team must understand that the I&T manager 
(by definition) manages the schedule. Any issues or 
conflicts should be brought to his or her attention as 
soon as possible after discovery, so that resources can 
be reallocated and the schedule can be adjusted, if 
necessary. 

2.3 Handling of Flight Hardware 
2.3.1 General I&T Practices 

Members of the I&T team, particularly those who will 
be directly handling the flight hardware, must be 
familiar with basic flight hardware handling practices. 
The following “common-sense” practices may seem 
trivial at first glance, but may ultimately be the keys to 
mission success and safety: 

• Minimize, if not eliminate, debris (“foreign-object 
debris,” or FOD) in I&T areas. This debris includes 
particulates, unneeded tools and equipment, 
extraneous paper and other consumables. Take the 
initiative to report facility cleanliness issues. 

• Before entering a clean environment, utilize shoe 
cleaners when available and properly don all 
necessary garments prior to entering. 

• Use gloves when handling cleaned flight hardware, 
including cable harnesses. Replace gloves as 
necessary to avoid contaminating clean hardware. 

• Use conductive gloves and wrist-stats when handling 
any h aid ware containing electronic components or 
ordnance. 

• Do not lay tools, test equipment, paperwork, or other 
miscellaneous items on top of flight 
hardware. 

• Fabricate or rework hardware in an area away from 
flight hardware, preferably in a separate lab (if 
feasible). 

• No personnel shall perform work on a powered-up 
payload unless that work is required to support the 
operation being conducted. Those I&T team 
personnel who must work in the vicinity of the 
payload should be notified when power is applied. 
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2.3.2 Electrical I&T Practices 

In addition to the recommended general practices, the 
following apply to personnel supporting electrical 
operations: 

• Minimize connector mates and demates whenever 
possible to avoid having to reverify interfaces and to 
help mitigate against connector failure. The latter 
can also be accomplished by using connector savers 
(if repeated demates are anticipated), or simply by 
exercising judicious consideration prior to demating. 
For example, if possible, perform electrical 
measurements from a ground-support equipment 
(GSE) interface rather than a flight one. 

• When using electrical test equipment, such as power 
supplies and break-out boxes, use proper leads and 
jumpers to minimize discontinuities and inadvertent 
shorts. If leads or jumpers are not available, fabricate 
new ones to support the job. 

• Label all cables and connectors. This includes correct 
cable and connector information on all ends of flight 
and GSE harnesses, and temporary labels (e.g., tape) 
on test equipment when appropriate. 

• After mating GSE cables or test equipment, provide 
adequate strain-relief support to harnesses. For 
example, nonflight ty-raps can be used to temporarily 
secure cables to brackets or dollies. 

• When demating connectors on any flight or ground 
equipment, grasp the connector, not the cable. 

• Cap unused connectors on flight cables and GSE, 
when appropriate, using anti-static caps (if 
available). 

2.3.3 Formal Training 

Beyond basic flight hardware handling practices are 
formal training courses for certification, such as 
electrostatic discharge (ESD) awareness, ordnance 
handling, soldering, crimping, and harnessing. Those 
persons involved with flight hardware fabrication and 
handling must be certified, and I&T engineers should 
consider certification themselves in case their hands- 
on services are required. Flight certifications also 
provide the knowledge necessary to evaluate proper 
flight hardware fabrication and handling performed by 
others. 


2.3.4 Ordnance Operations 

Flandling of ordnance is usually performed by the lead 
engineer or technician for the system using the 
ordnance. For example, in the case of Flitchhiker 
ejection systems, the carrier mechanical team usually 
retrieves NASA Standard Initiators (NSIs) from the 
storage facility and installs them into the flight 
hardware. 

Flandling of ordnance requires the use of “wrist-stats,” 
even when contacting hardware in which NSIs are 
installed. Flardware should be tagged with “ordnance 
installed” signs or streamers. The hazardous operations 
area should be cordoned off and restricted to only those 
directly involved with the operations. 

While ordnance operations are being performed, the 
I&T manager or task leader should monitor the 
immediate area for nonessential personnel or activities. 
If it takes yelling to get someone’s attention to prevent 
a hazardous situation, so be it; better this than to have a 
hand blown off by an explosive device. 

Regardless of whether the ordnance system is flight or 
not, the individual handling the ordnance must be 
properly trained and certified to do so. Those performing 
operations with the ordnance system following 
integration (such as installing arm plugs) must also be 
certified in ESD awareness and pyrotechnic operations. 
Unfortunately, with the exception of KSC’s training, 
good courses for ordnance handling are difficult to find. 

2.3.5 Troubleshooting Anomalies 

All anomalies should be fully investigated and 
understood. It is recommended, however, to start with 
a troubleshooting plan to proceed in an orderly manner 
and to avoid unnecessary violation of interfaces. 

Some rules of thumb for troubleshooting arc: 

• Avoid deactivation of the payload or instrument, or 
rebooting of software, until as much information as 
possible is obtained about the problem. 

• It is usually best to start troubleshooting the ground 
system first, and then those flight items that are least 
intrusive to the flight configuration. 

• To help isolate the problem, only one change to the 
flight or ground configurations should be made at a 
time. 
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• Although hardware should be “built to print,” 
occasionally drawing errors occur. Therefore, do not 
always assume that the released engineering 
accurately reflects the current hardware 
configuration. 

• As much detail as possible should be recorded in 
the logbook (or in the procedure), regardless of how 
insignificant it may seem. This data may prove useful 
later on, for example, to help determine the exact 
configuration at any point in the troubleshooting. 

• Notes and data should be recorded in real time rather 
than reconstructed after the fact. 

Once a problem is isolated, consider deliberately 
repeating the problem (if possible) to obtain conclusive 
proof. Every effort should be made to explain any 
anomalies fully, especially those that are intermittent. 
Any deemed unexplained may come back to haunt you. 

2.5 I&T Manager Communications 

2.5.1 Communication With I&T Team 

Communication among I&T team members is of utmost 
importance for the smooth and safe performance of 
payload I&T. The focal point for this communication 
is the I&T manager, who is the single-point contact for 
payload I&T at both the development facility and launch 
site. In this capacity, the I&T manager can disseminate 
information regarding individual payload subsystems 
and customers among the entire I&T team. This role of 
the I&T manager also helps to avoid multiple requests 
for support and resources throughout I&T. 

It is the responsibility of the I&T manager to regularly 
inform the team regarding the I&T schedule and status. 
Conversely, to do his or her job effectively, the I&T 
manager must likewise be kept infoimed of any changes 
to the I&T schedule, and be notified of any delays or 
support conflicts as soon as possible. 

Prior to a significant operation, such as a payload test 
procedure, a pretest briefing should be held with all 
participants. This short meeting, usually hosted by the 
task leader, includes: 

• Distribution of copies of the released procedure and 
any deviations (“devs”) from which participants can 
work or follow along 


• Identification of key personnel and responsibilities, 
with the task leader as the primary contact for all 
operations 

• Discussion of potential hazards and controls (e.g., 
emergency power down) 

• Directing that no unrelated work is to be performed 
on the payload while power is applied. 

Finally, good communication with the I&T team depends 
on the I&T manager’s openness to alternative suggestions, 
whether solicited or not. Personal opinion should take a 
back seat to safety and doing what makes sense. 

2.5.2 Communication With Payload Customers 

Besides communication with the I&T team, that with 
the payload customers is also important. Customers 
should be encouraged to communicate with the I&T 
manager on a regular basis, in an “open door” policy. 
The I&T manager should be informed well in advance 
about any planned customer operations or requirements, 
and be notified as soon as possible regarding any 
unplanned activities. Again, customers should approach 
the I&T manager with requests for support or I&T- 
related issues. 

In the case of KSC operations, customers should be 
reminded to go through the I&T manager for special 
requests to KSC. This approach helps to minimize 
redundant, multiple requests to KSC personnel and 
helps keep the I&T manager informed about customer 
operations. 

2.5.3 Communication With KSC 

As mentioned earlier, the I&T manager is considered 
the single-point contact for all integration and test 
activities at both GSFC and KSC. As such, the I&T 
manager must be kept informed of all carrier and 
experiment plans and activities. This information will 
help ensure availability of resources, proper operational 
sequencing, and safe implementation. 

The Future Payload Manager (or FPM, formerly the 
Faunch Site Support Manager) is considered the I&T 
manager’s contact for communications with KSC. This 
communication path helps to minimize extraneous or 
erroneous communications. Of course, some technical 
details will still require direct discussion among specific 
discipline engineers. 
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The I&T manager is usually in frequent contact with 
the FPM during the final weeks leading up to delivery 
to KSC. Part of this information exchange includes 
regular updates regarding the expected arrival date, as 
well as any unique support requirements. This allows 
the FPM to keep the KSC payload processing team 
(PPT) informed and therefore better prepared to receive 
the payload, support equipment, and personnel. The 
I&T manager may also participate in weekly PPT 
meetings via teleconference. 

3. PROCESS DOCUMENTATION AND 
CONFIGURATION MANAGEMENT 

3.1 Payload Project Configuration 
Management 

3.1.1 Scope 

Even before the introduction of IS 0-9000 requirements, 
process documentation and configuration management 
(CM) have played an important paid in NASA flight 
projects. Process documentation includes certification 
logs, as-run procedures, problem reports, and other 
“quality records.” CM involves maintaining an archive 
system of as-built hardware and software configuration, 
including requirements, procedures, and drawings. 
Compared to some larger projects, CM for small 
payload projects should be a more streamlined and user- 
friendly system. 

In the case of the SSPPO, a CM office and Configuration 
Control Board (CCB) have been established to track 
configuration, release documentation, and process 
Configuration Change Requests (CCRs). CCRs are 
required for all changes to the baselined flight 
configuration. 

Each small payload project must decide to what extent 
CM will be established and enforced. Some form of 
CM is advisable, however, for accountability and 
tracking as-built configurations for all spaceflight 
projects. 

3.1.2 I&T Considerations 

Depending on the CM approach established by the 
payload project, it is the responsibility of the I&T 
manager to ensure that: 

• All new hardware is fabricated to released 
drawings 


• All modifications are documented and approved 

• All operations are worked to a released plan, drawing, 
and/or procedure 

• All as-run procedures are fully annotated and then 
maintained in an I&T logbook 

• All anomalies are documented and maintained in the 
I&T logbook. 

3.1.3 Nonconformances 

Any nonconformances or anomalies encountered 
should be documented to allow hacking, as well as to 
provide a historical record. The level and extent of 
problem documentation depends on the individual 
project. As mentioned earlier, any troubleshooting 
should be deliberate and well documented. 

A corrective action should be documented by whatever 
mechanism the project has established (problem record, 
logbook, etc.). A required modification that affects 
released engineering drawings should also be formally 
documented. 

3.2 Customer “CM” 

3.2.1 Documentation 

Although individual customers are not always bound 
by the payload project’s CM requirements, it is still 
important (particularly for flight safety) to ensure that 
the instrument as-built configuration is consistent with 
the documentation. For the purposes of I&T, accurate, 
organized, and complete documentation provides an 
invaluable source of information if troubleshooting 
becomes necessary. 

For these reasons, instrument developers should keep 
logs and drawings showing the as-built configuration 
of their system. This documentation can help ensure 
that the payload safety review process, as well as I&T 
itself, proceeds smoothly. 

Documentation that is useful to maintain during the 
course of instrument development includes: 

• Test and assembly logs, including records of any 
anomalies and modifications 

• Certificates of compliance for materials and 
components, including those provided by vendors 
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• Record of Mandatory Inspection Points (MIPs) to 
verify safety items and as-built configuration 

• Up-to-date mechanical drawings and electrical 
schematics, including fuse and wire sizes 

• Parts and materials lists, with Material Safety Data 
Sheets (MSDSs) for hazardous materials (hazmats) 

• Fastener certifications and logs, including torque 
levels 

• Summary of open items or problems, if any, to be 
addressed following delivery for payload 
integration. 

3.2.2 The CCCR 

Besides the as-built configuration and certification data 
mentioned, post-delivery CM of the instruments is also 
important. For example, customer hardware or software 
is sometimes modified following delivery to effect 
enhancements or correct problems. Such changes must 
be brought to the attention of payload project personnel 
to ensure that even seemingly benign modifications will 
not compromise flight safety or mission success. Since 
small payload projects generally do not maintain 
configuration of customer hardware or software, other 
means should be established to help identify and Pack 
customer changes. 

The SSPPO has instituted a process by which customer 
modifications can have greater visibility and review for 
potential impacts. Following hardware delivery to 
GSFC, customers are requested to complete and submit 
a Customer Configuration Change Request (CCCR) for 
any changes to flight or nonflight hardware or software 
from that originally approved for use. Since the CCCR 
is used simply as a communication tool, it imposes no 
CM requirements on the customer. The sample form 
can be found in the SSPPO’s “Customer 
Accommodations and Requirements Specifications” 
(CARS) document [4]. 

4. PAYLOAD DEVELOPMENT 

4.1 Payload Carrier 

4.1.1 I&T Considerations 

From the very beginning of payload carrier 
development, all I&T aspects must be considered. 
Therefore, I&T personnel must participate in the design 


of new carrier systems so that the final product design 
takes into account real-world integration issues. 
Experienced I&T input will help ensure that, once the 
new carrier is developed, it can be integrated as 
efficiently and safely as possible. For example, on some 
Hitchhiker payloads, test connectors are strategically 
placed to allow easy access for testing in the orbiter. 

There is one important point regarding design for 
electrical interface verification: All final electrical 
connections must be verified for flight, either 
functionally or by continuity measurement. This means 
that interfaces that cannot be powered following final 
connection, such as arm plugs for ordnance circuits, 
must be designed with a parallel test connector to allow 
verification that all circuits are intact after mating of 
the flight circuit. 

Finally, all items to be handled in the orbiter, such as 
dust covers or safe/arm plugs, must be designed to be 
tetherable for handling and secure when installed. In 
the case of one shuttle payload, a customer’s dust cover 
was only pressure-fit onto an instrument’s horizontal- 
oriented aperture. When the payload was on the pad 
and a Titan was launched a few miles away, the cover 
vibrated loose, impacting and damaging another 
payload installed in the bay below. 

4.1.2 New Hardware Testing 

Requirements for environmental testing of new 
components or subsystems should be clearly defined 
in a test plan. For SSPPO payloads, requirements are 
based on specifications defined in the Goddard 
Environmental Verification Specifications (GEVS) 
document [5] and the Shuttle “Core” ICD [6]. 

Environmental testing performed on new components 
or subsystems typically includes, at a minimum, 
vibration and thermal- vacuum tests. In the case of 
Hitchhiker, the only environmental testing performed 
at the integrated payload level is electromagnetic 
compatibility (EMC). For payloads involving safety- 
critical circuits, all inhibits are enabled during 
environmental testing to ensure safety is maintained 
during worst-case conditions. 

For flight mechanical components being developed, 
preintegration fit-checking is recommended whenever 
possible. History has shown that, despite the best 
drawings, actual hardware may not always fit 
properly. 
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4.1.3 Flight Hardware Reuse 

The Hitchhiker project has the luxury of reusing the 
majority of its carrier hardware from mission to mission. 
Carrier components that already exist are selected for 
reflight, with new hardware fabricated only as 
necessary. Existing hardware to be reused is usually 
not required to undergo requalification testing but must, 
at a minimum, be thoroughly inspected prior to reflight. 

In the case of Hitchhiker electronics assemblies, 
typically only those circuits to be used for the assigned 
mission are refurbished and tested. This work includes 
replacing fuses and performing bench-level functional 
testing. Electrical harnesses are selected from an 
extensive “library” of previously flown cables. Of 
course, as more payloads are flown, more cables 
become available from which to choose. 

4.1.4 Flight and Ground Software 

Flight software for shuttle small payloads may include 
C&DH software internal to the payload itself, or that 
installed as part of the Payload and General Support 
Computer (PGSC) flight load. Verification usually 
involves testing with the hardware (either a simulator 
or flight). The payload-unique flight software is then 
sent to Johnson Space Center (JSC) to be included in 
the PGSC flight load for the mission. 

Although initial PGSC software testing may be 
conducted with a laptop simulator, final testing with 
the integrated payload should be performed using a JSC- 
provided, flight -like PGSC. PGSC loaners are requested 
from JSC via a Request For Support (RFS) form for 
periods of 2 weeks at a time. 

If a ground command and telemetry system is being 
used to support payload I&T, any displays and 
procedures arc (ideally) baselined by the start of testing. 
Periodic training of test team personnel is 
recommended. Utilizing the same ground system for 
both I&T and mission operations, as is done for 
Hitchhiker, is obviously preferable and most efficient. 

4.2 Customer Instrument 

4.2.1 Customer-to-Carrier Interfaces and 
Requirements 

Small payload customer interfaces and requirements, 
including those for ground operations support, must be 


clearly defined in advance. These items are usually 
specified in a payload-to-customer ICD, based on a 
customer requirements document. Details of 
mechanical and electrical interfaces are usually included 
in drawings referenced in each ICD. 

Some examples of requirements included in the 
payload-to-customer ICD (or on referenced drawings) 
are: 

• Electrical interfaces: command, telemetry, video, 
recording, PGSC (including software) 

• Mechanical interfaces: fasteners, mounting 
locations, orientation, handling 

• Thermal interfaces: heaters, blankets, mission 
thermal modeling 

• Ground support equipment: GSE, slings, and 
containers 

• Servicing: purging, battery charging, accessibility 

• Safety: hazmats, operations 

• I&T issues: cleanliness, tethering, temperature and 
humidity constraints, radiation sensitivity (e.g., x 
rays). 

Any customer requirements not documented in advance 
should be considered new requirements. These must 
be assessed for whatever additional support or resources 
may be required, and may be an “optional service” not 
normally provided by the carrier organization. The ICD 
or requirements documents should then be modified to 
include the new requirements. 

Those requirements involving KSC operations are 
included in PIP Annex 8 (Launch Site Support Plan, or 
LSSP), and possibly Annex 9 (Operations and 
Maintenance Requirements and Specifications 
Document, or OMRSD) if any involve interface 
verification, unique environmental constraints, or stand- 
alone payload operations in the orbiter. The latter 
include testing, battery top-charging, cover removals, 
etc. It is important that a customer’s requirements are 
clearly understood as either mandatory or “highly 
desired.” Customers may need to be reminded that 
shuttle small payloads are usually “secondary” 
payloads, and as such have little clout when it comes to 
driving KSC operations, such as payload-bay door 
opening at the pad. 
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4.2.2 I&T Considerations 

As with the payload carrier. I&T issues related to the 
customer should be considered during the development 
phase. First, customer hardware design and flight 
configuration should be formally documented on 
released engineering drawings. This is especially 
important for those components that could be integrated 
with the carrier in more than one orientation. 

For customer hardware requiring late access in the 
orbiter, accessibility must be considered in the design 
phase, as mentioned earlier for carrier hardware design. 
For example, interfaces for test connections, purges, 
and other prelaunch operations should be accessible 
from step-ups, “pic” boards, or other platforms. The 
same is true for “remove-before-flight” items, such as 
lens covers and drag-on purge lines. Use of the Orbiter 
Processing Facility (OPF) “bridge bucket” for access 
to the payload is strongly discouraged due to its 
operational complexity, limited availability, and 
increased risk of damage to flight hardware. 

4.2.3 Preintegration Testing 

It is strongly recommended that customers complete 
all environmental testing prior to delivery for final flight 
integration. Once the entire payload is integrated, it is 
difficult or impossible to correct any problems or shuttle 
ICD exceedances, such as might be discovered during 
EMC testing. Not only could the customer hardware 
be virtually inaccessible within the integrated payload, 
but the KSC delivery schedule may not allow time to 
modify hardware late in the flow. 

Besides the usual qualification and acceptance testing, 
customer preintegration testing with the carrier is also 
recommended. Preintegration testing provides 
customers an opportunity to verify function of both 
flight and ground system interfaces well in advance of 
flight integration. It is usually performed early enough 
to allow time to make any modifications, if necessary, 
prior to final delivery. 

Preintegration tests can be performed using customer 
prototype or flight hardware (or software) in 
development. Any testing of the customer interfaces 
with the carrier prior to delivery is helpful, even if just 
to check ground system interfaces. 


Preintegration testing also provides an opportunity to 
perform a “dry run” of I&T procedures, to verify the 
inaccuracy prior to final delivery. This also serves to 
document the as-run operation for future reference 
during flight I&T. 

5. PAYLOAD INTEGRATION 

5.1 Carrier Integration Sequence 

Integration of individual payload components should 
be performed in the most logical sequence. 
Implementation of a logical integration sequence, 
however, depends on several factors. These include 
hardware availability, integrated component 
accessibility, and functional interdependence. 

For example, integration of payload carrier components 
should be completed prior to interfacing with customer 
hardware. Also, routing of harnesses for flight should 
be performed only after all functional testing of the 
particular end item is complete. Thermal blankets may 
or may not have to be installed prior to final flight 
connections, depending on whether they have been 
designed to allow installation over connected cables. 

Regardless of the I&T sequence, the I&T manager must 
understand all the subtle requirements of the I&T flow. 
Fie or she should make the I&T flow clear to the I&T 
team (via meetings, schedules, I&T plan, etc.), yet 
remain open to alternative suggestions from other team 
members. Again, the important point is to do what 
makes sense. 

5.2 Customer I&T 

5.2.1 Customer Predelivery Preparations 

Customer procedures (planned and contingency) 
required for I&T should be submitted to the payload 
organization no later than 1 month prior to delivery. 
This deadline allows adequate time for review and 
modification, if necessary, prior to customer arrival. 
Customers should be strongly encouraged to perform 
dry runs of their procedures at their home facilities. 
These “rehearsals” will not only provide familiarization 
with the procedures themselves, but may also help 
reveal problems or discrepancies with the hardware or 
software that may need to be addressed. 
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Customers should also be advised to avoid last-minute 
design changes to hardware or software. This is 
particularly important with respect to changes involving 
mechanical and electrical interfaces to the carrier. This 
restriction also applies to customer commands required 
to be sent during the payload-to-orbiter interface 
verification test (IVT); this is because such commands 
are defined in advance in the PIP Annex 4 (Command 
and Data Annex) and incorporated into KSC’s Launch 
Processing System (LPS) software. If late modifications 
to hardware or software are deemed necessary, then the 
as-built documentation must be updated accordingly, 
including any inputs to the safety data packages. 

The customer-to-carrier ICD should also reflect the 
latest payload interface and I&T requirements. Any last- 
minute changes to the ICD should be approved by the 
payload carrier and customer prior to customer 
hardware delivery. 

To support payload-level I&T, customers should be 
reminded to bring their instrument test and assembly 
logs, schematics, unique tools, test equipment, and 
consumables. Customers should also bring flight- 
qualified spares for critical components, as these may 
involve a long-lead time for delivery. 

5.2.2 Customer Delivery 

Unless prior arrangements have been agreed to, the 
customer is expected to deliver the instrument and GSE 
ready for integration with the payload carrier. The only 
operations to perform prior to carrier I&T are typically 
receiving and inspection, and any postship functional 
testing of the instrument. 

Shortly after the customer arrives, a “tum-over” meeting 
is held with the customer and I&T team. Some I&T- 
related items that should be addressed during the 
meeting are: 

• Status of carrier flight and ground systems 

• Status of customer flight and ground systems 

• Plan for integration and test, including schedule, 
location, personnel assignments, and hazards 

• Distribution of customer and carrier procedures 

• Deviations to procedures previously identified, either 
planned or contingency 

• Any explained or unexplained anomalies 


• Open customer work to be performed, either before 
or after start of carrier integration 

• Unique customer requirements (alignment, purge, 
calibration, charging, etc.), if any 

• Customer responsibility for shipping, handling, and 
storage of their own equipment 

• Customer support area (i.e., office space). 

5.2.3 Customer-to-Carrier I&T 

Following completion of any postship stand-alone 
functional testing, the customer hardware is 
mechanically integrated with the payload carrier. This 
may be as simple as bolting a small box to a mounting 
plate, or as complex as crane-lifting a large sensor onto 
a pointing subsystem requiring subsequent optical 
alignment. 

Prior to electrical connection to the carrier power and 
C&DH subsystems, resistance measurements should be 
taken at the customer interface to verify proper 
continuity and isolation, as applicable. Following 
electrical connections for flight, a functional test is 
performed to verify the final flight interfaces between 
the customer and carrier. 

It is advisable to restrict activation of individual 
instruments to times when a customer representative is 
present to monitor instrument status. One exception to 
this rule is when the customer is able to monitor the 
instrument telemetry from a remote Payload Operations 
Control Center (POCC). 

5.3 Payload-Level I&T 

5.3.1 Final Integration 

After all hardware is installed, the payload should be 
configured as close as possible to flight. This work 
includes securing all thermal blankets and cable 
harnesses. It may be desirable to delay installation of 
lock- wiring and staking in case removal of hardware is 
required to address any problems encountered during 
payload testing. 

5.3.2 IVT Simulations 

To ensure that the orbiter IVT sequence is correct, as 
well as to familiarize the team with the IVT procedure. 
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IVT simulations (“sims”) are conducted. These sims 
are performed with the payload in the flight 
configuration, with the latest version (or draft) of the 
IVT procedure. IVT sims should be performed upon 
completion of payload integration at the carrier facility, 
and then upon completion of Payload Processing 
Facility (PPF) testing at KSC just prior to orbiter 
integration. 

For those payloads utilizing a PGSC, it is important to 
use the latest mission software available from JSC. The 
“training load” software is usually not available, 
however, until launch (L)- 110 days. The final flight load 
is not released until approximately L-40 days. 

Since the PGSC software used during the IVT sim may 
not be the final version, JSC should notify the payload 
of any changes to the flight load following initial release. 
This notification allows enough time for the payload- 
unique software to be modified and tested, if necessary, 
prior to the orbiter IVT. 

All individuals who plan to support the actual orbiter 
IVT should participate in the IVT sims, including 
members of the I&T team and any customers. Having 
the same people for both tests is especially important 
for subjective verifications, such as those for closed- 
circuit television (CCTV) images. It also helps 
familiarize everyone with the procedure and associated 
verifications prior to the orbiter IVT. 

If crew is available, such as a payload specialist, then 
he or she should also participate in the IVT sims for 
the familiarization opportunity. In this case, the crew 
should be kept informed of the test schedule, which 
may need to be adjusted to accommodate their 
availability. 

5.3.3 Transfer to EMC 

Upon completion of customer-to-carrier integration, the 
payload is transferred to an EMC test facility. 
Performing EMC testing on the payload in flight 
configuration is important to accurately test for 
emissions and susceptibility. Testing is based on the 
latest EMC limits identified in the shuttle “Core” ICD. 

For payloads involving safety-critical circuits, all 
inhibits must be enabled during EMC testing to verify 
no susceptibility. For example, any ordnance should be 
installed and connected, and the system fully armed. 


Ordnance integrity should be verified at regular intervals 
during susceptibility testing (such as the end of each 
test day) to limit the amount of retest required if 
susceptibility is discovered. 

EMC test data that indicate any exceedances are 
provided to JSC for review. Exceedances approved for 
flight are eventually documented in the payload-to- 
orbiter ICD. Those not approved are mitigated through 
redesign (such as incorporation of electromagnetic 
interference filters) or operationally (e.g., not activating 
the emissions-producing hardware). 

5.3.4 Telemetry Recording 

If a payload has any telemetry interfaces, data should 
be recorded during I&T for later playback during 
mission simulations. Ideally, this telemetry should 
reflect payload configurations expected during the 
mission, and therefore requires that each subsystem and 
instrument be operated in various on-orbit modes. 

For any ground data GSE to be used during both I&T 
and the mission itself, two sets of GSE are 
recommended. This will allow support of mission sims 
during prelaunch I&T, as well as provide a back-up if 
the primary set fails. 

6. PREPARATIONS FOR LAUNCH SITE 
OPERATIONS 

6.1 Documentation 

6.1.1 Orbiter Documentation 

Usually before the Cargo Integration Review (CIR), 
approximately 1 year prior to launch, the payload 
provides inputs to such programmatic documentation 
as the payload-to-orbiter ICD, the PIP and annexes, and 
detailed orbiter schematics. The I&T manager and 
engineers should thoroughly review this documentation 
for accuracy. 

In the case of the PIP Annex 4, confirmation of 
command bit patterns is especially important. This is 
because KSC uses the Command and Data Annex to 
generate Payload Signal Processor (PSP) commands 
sent via the LPS during the orbiter IVT. Any 
discrepancies are difficult to identify and correct while 
the IVT is in progress. 
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The OMRSD is used to ensure that a requirement is 
formally levied on KSC. Compared to the LSSP, the 
OMRSD affords greater visibility and tracking, 
especially in the orbiter world. It is also important to 
remember that the OMRSD is meant to specify what 
requirements need to be fulfilled, not how they are to 
be implemented; those details are left for the 
procedures. 

As orbiter integration becomes imminent, tech orders 
(TOs) are generated by orbiter engineering to document 
the details necessary to integrate a particular payload. 
The individual discipline engineers should review the 
TOs to ensure technical accuracy, well in advance of 
orbiter integration. 

6.1.2 KSC Documentation 

The payload organization works with KSC on most of 
the documentation related to processing the payload. 
This includes the LSSP and Program Requirements 
Document (PRD), as well as work authorization 
documents (WADs) such as Test Preparation Sheets 
(TPSs) and Operations and Maintenance Instructions 
(OMIs). All of these must be reviewed thoroughly for 
accuracy during the draft phase to avoid having to 
modify a document after it is released. As with payload 
inputs to KSC, procedures should be submitted to the 
payload for review 45 days prior to first use. 

Even before the KSC procedures are written, payload 
requirements must be specified in the LSSP and 
OMRSD. Facility, consumable, and other support 
requirements are included in the PRD. Also, any 
hazardous operations requiring KSC support (e.g., pad 
clears, RF-silence, etc.) should be explicitly identified 
in the LSSP and/or PRD. 

6.1.3 Payload Procedures 

Although the format for payload procedures is generally 
up to the payload provider, it is preferable to write 
payload procedures in the same format as KSC 
procedures. This approach helps not only to translate 
to the KSC format if needed for KSC WADs. but also 
helps familiarize the payload team with the KSC format. 

Hazardous procedures usually require KSC-specific 
wording and formatting. The distinction between 
hazardous and nonhazardous procedures is outlined in 
KHB- 1700.7 [7], with which the I&T team should be 
familiar. 


Currently, all payload procedures (planned and 
contingency) are due to KSC 45 days prior to first use. 

6.2 Personnel Training and Badging 

Note: As of the date of publication, security 
requirements at NASA facilities were being revised. It 
is recommended that the I&T manager verify the latest 
KSC security requirements and ensure payload team 
compliance prior to payload delivery. 

6.2.1 Types of Badging 

All payload personnel, NASA and non-NASA, must 
be properly trained and badged to enter and work at 
KSC facilities. Two types of badging are in force at 
KSC: the first allows access onto Government property, 
and basically requires either a permanent picture badge 
or a temporary “machine pass.” The second allows entry 
into designated areas and facilities, and requires an area 
permit that can be either permanent (for which a 
Personnel Access Control Accountability System, or 
PACAS, badge is issued) or temporary (for which a 
Temporary Area Authorization, or TAA, is issued). The 
latter can be either for escorted or unescorted access. 

It is recommended that the entire payload support team 
obtain unescorted access, not only because they will 
probably require periodic long-term access to KSC 
facilities, but also because they can help escort 
customers if necessary. For payload customers, escorted 
badging is usually sufficient since most are only one- 
time visitors; no special training is required in this case. 
For those customers with anticipated long-term or 
multiple visits to KSC, unescorted access is 
recommended. 

6.2.2 Training Requirements 

Those persons requiring unescorted access to KSC 
facilities must also be trained in emergency egress, 
including use of the Emergency Life Support Apparatus 
(ELSA) and the respective facility “walk-downs” 
(usually on video). There are also several general safety 
videos that must be viewed. 

Unescorted access also requires that a full Personnel 
Reliability Profile (PRP) security investigation of the 
individual be conducted. Unfortunately, the process is 
quite lengthy, requiring personal history details 
submitted usually a year in advance. Although one’s 
PRP approval can be renewed, the entire investigation 
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process must be reperformed if it lapses for an extended 
period. 

In addition, anyone requiring access to elevated 
platforms must be trained in fall protection, which 
involves use of body harnesses tethered to support 
structures. Anyone involved in use of hazardous 
materials (including solvents and staking compounds) 
must be trained in “hazardous waste handling.” Finally, 
anyone requiring access to the orbiter must view the 
midbody and crew module familiarization video. 

Training and certifications must be kept up-to-date such 
that personnel are certified for the duration of scheduled 
operations. As much training as possible should be 
completed before start of KSC operations so time at 
the Cape can be used most effectively. 

6.3 Shipping 

6.3.1 Arrangements 

About a year before going to KSC, the I&T manager 
(or designee) should initiate Dept, of Transportation 
(DOT) approval for shipment. Requests must begin this 
early to allow for DOT processing time, especially if 
hazmats, such as volatile chemicals, radioactive 
substances or explosives, are involved. If shipping via 
highway is ultimately denied, alternatives modes of 
transport include plane and barge. The latter was 
necessary to ship the CAPL-1 Flitchhiker (STS-60) due 
to its relatively large quantity of ammonia. Since then, 
GSFC has obtained a global DOT exemption for 
shipping up to 0.25 lbs of ammonia per heat pipe. 

Other issues that need to be addressed prior to shipment 
include: 

• Generation of a shipping list, including up-to-date 
MSDSs and a hazmat checklist 

• Contracting and scheduling the truck 

• Arranging for truck driver badging at KSC, and 
providing specific directions to the driver 

• Generation of a shipper and verifying it against the 
items loaded onto the truck. 

6.3.2 More on Hazmats 

All hazardous materials must be identified in advance 
for GSFC and KSC processing safety, as well as for 


shipment. Those items that should be assumed 
hazardous until proven innocent include chemicals, 
gases, radioactive materials, and ordnance. Small 
commercial, off-the-shelf batteries are not considered 
hazmat items, although other larger batteries may need 
to be identified. 

Hazmats contained within payloads approved for 
shipment must again be properly classified as a 
hazardous material on shipper, with an MSDS included. 
Hand carrying hazmats is prohibited. Special 
requirements may also apply for radioactive materials. 

6.3.3 Loading and Shipment 

Although shipping requirements depend on such things 
as payload size and sensitivity, the payload and GSE 
can usually be shipped in an environmentally controlled 
moving van. 

The actual day of shipment to KSC depends on the 
amount of time required for postship I&T prior to orbiter 
integration. To take the most advantage of the work 
week at KSC, it is usually advantageous to ship over a 
weekend for arrival early Monday morning. The FPM 
should be contacted to arrange for entrance of the truck 
and personnel onto KSC. 

Finally, it is traditional to have plenty of payload stickers 
or other “goodies” on hand for the movers and any other 
support personnel. 

6.4 Miscellaneous Preship Considerations 

6.4.1 GSE Certification 

Mechanical ground support equipment (MGSE), such 
as lifting slings, must be proof-loaded and certified to 
lift flight hardware. This certification is valid for only 
1 year, which is usually sufficient to support both 
prelaunch and postlanding operations for small 
payloads. Therefore, it is desirable to have the MGSE 
proof-loaded as late as possible just prior to shipping, 
with a couple of weeks added for contingency. 

Also, electronic test equipment (such as meters) should 
be calibrated prior to shipment. Since meters and other 
electrical GSE (EGSE) are readily available at KSC, 
their last-minute calibration is not as critical as for 
MGSE. 
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6.4.2 Payload Bay Cabling 

Some Hitchhiker cables, such as cross-bay cables, are 
installed by KSC into the payload bay prior to payload 
installation. These should be shipped to KSC well in 
advance of being required for integration into the orbiter. 
If time allows, the cables should be transported with 
the payload; otherwise, they must be shipped in advance 
(along with the flight certification documentation). If 
advance shipment is required, and additional payload 
testing (such as EMC) is to be performed, then a second 
set of cables is necessary. 

6.4.3 Preship and Configuration Reviews 

As is usual for flight projects, an “in-house” preship 
review is conducted prior to shipment to launch site. 
This serves as a forum to verify that there are no 
hardware configuration issues, nonconformances, or 
anomalies to be addressed. Ideally, the preship review 
is scheduled immediately following the EMC test so 
any exceedances can also be presented. The review is 
also the last opportunity to verify that all 
documentation — certification logs, problem records, 
procedures, ground safety verification items, etc. — is 
up-to-date. 

Usually prior to the preship review, a separate review 
is conducted to identify any configuration discrepancies 
between the hardware and orbiter documentation. 
Conducting this configuration review before shipment 
allows enough time to correct any discrepancies before 
orbiter integration. A final survey is conducted at the 
PPF, just prior to transfer to the orbiter, to cover any 
items integrated in the field. 

6.4.4 Things to Bring 

The following is a nonexhaustive list of items the I&T 
manager should bring (or arrange to be shipped) to 
KSC: 

• Latest versions of procedures (payload stand-alone 
or KSC), including any modifications 

• Latest payload drawings, including all cable 
assembly drawings and earl ier schematics 

• Excerpts from the payload-to-orbiter ICD, 
particularly the technical details 

• Latest PIP and annexes 

• Certification logs and as-run copies of procedures 
performed during payload I&T 


• Contact information for key personnel at home and 
at KSC 

• Badges (picture and KSC Area Permit) and any 
certification cards 

• Stickers, pins, or patches for KSC support 
personnel. 

7. PRELAUNCH OPERATIONS 

7.1 General 

7.1.1 I&T Manager’s Role at KSC 

While at KSC, the I&T manager fulfills several 
functions. First, he or she continues to be the focal point 
for payload I&T operations. The I&T manager works 
closely with the FPM, through whom KSC support and 
resources are requested. 

Second, the I&T manager serves as the payload test 
conductor, or TC. In this capacity, the I&T manager is 
the primary payload contact during the orbiter IVT and 
other integrated operations. As such, he or she is the 
communication link between the payload and KSC 
teams on the Operational Intercommunication System 
(OIS) “net.” 

Third, the I&T manager also has the role of launch site 
safety representative for the payload. Therefore, he or 
she must be familiar with all safety issues associated 
with processing the payload at KSC. 

Finally, the I&T manager has payload signature 
authority for approval of KSC WADs and sign-off of 
the as-run procedures. In this capacity, he or she may 
also sign off the payload closeouts for flight. 

7.1.2 Miscellaneous I&T Considerations 

Following arrival at KSC, daily I&T meetings with a 
summary of operations for the week are usually helpful. 
Depending on the number of participants and space 
available, these can be relatively informal stand-up 
meetings with the team. Pretask briefings, especially 
for major tests and hazardous operations, should be 
considered mandatory. KSC personnel involved in the 
operations should also be invited to attend. 

Any overtime, whether daily or weekly, should be 
coordinated through KSC and payload management to 
comply with work restrictions. More importantly, 
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personnel fatigue increases the risk of accidental injuries 
or damage to flight hardware. Any extension or 
rescheduling of operations should be decided upon with 
due consideration to the I&T team, which is typically 
“single string” for small payloads. 

7.1.3 Hazardous Operations 

During hazardous operations, such as testing and arming 
of ordnance, the I&T manager must ensure that the 
operation has been identified as hazardous. This effort 
includes scheduling RF-silence (if necessary) and 
requesting a local clear area (typically 10 feet from the 
hardware). For some hazardous operations a local clear 
is sufficient, with only a cordoned-off area in the 
immediate vicinity of the operation. RF-silence, clear 
areas, and any emergency steps should be called out in 
the associated WAD. 

The KSC payload operations (ops) representative is 
responsible for ensuring that other personnel are notified 
about hazardous operations in the clear area. The area 
should be monitored for unauthorized entry and 
questionable activities. Those directly involved with 
performing hazardous operations must be trained and 
certified. 

7.1.4 Data Transfer 

Occasionally, data must be transferred from the payload 
organization to KSC. This data includes final payload 
weight and center of gravity (eg), and any information 
required for safety verifications and OMRSD 
requirements. 

Since there is no formal mechanism to handle data 
transfer between the payload and KSC, it is 
recommended that the payload develop a form similar 
to SSPPO’s “GSFC Data Transfer Form.” A copy of 
this form may be obtained from the SSPPO CM Office 
at GSFC. 

Likewise, as-run data from KSC WADs must sometimes 
be transferred from KSC to the payload. In this case, it 
behooves the I&T manager to request any required KSC 
data via the LSSP At a minimum, KSC should be 
provided with advance notice that the as-run data will 
be needed. 

7.1.5 Customer Access to Orbiter Facilities 

Understandably, many payload customers may want to 
tour the various orbiter integration facilities (OIFs), as 


well as the orbiter itself. Such tours may be acceptable 
during a break in I&T, for example, or with only a 
couple of visitors. For larger groups, a separate tour is 
recommended as schedules permit. 

During critical integrated operations, however, such as 
orbiter installation or IVT, visitors not involved with 
the operation itself should not be permitted in the area. 
Finally, no visitors should be allowed inside the orbiter 
crew compartment unless there is sufficient justification. 
This restriction is based on the high density of critical 
components in the crew module, as well as to “man- 
loading” limits. 

7.1.6 Operational Responsibilities at KSC 

Depending on the nature of the operation involving 
shuttle payloads, either KSC or the payload has primary 
responsibility, with the other acting in a support role. 
KSC personnel have primary responsibility for 
performing most of the payload-to-orbiter integration 
operations. The payload representatives are responsible 
for performing those operations that involve payload- 
to-payload interfaces. These include not only payload 
flight interfaces, but nonflight ones such as test 
connections for payload GSE. 


A summary of general categories of operations and the 
primary responsible party for each is shown below: 


Primary 

Operation Responsibility 

Payload operations at the 
payload processing facility 

Payload 

Integration and deintegration 
involving payload-to-orbiter 
interfaces 

KSC 

Integration and deintegration 
during orbiter operations 
involving payload-to-payload 
interfaces 

Payload 

Payload testing involving payload-to- 
orbiter interfaces 

KSC 

Payload testing during orbiter 
operations involving payload-to-payload 
or payload-to-GSE interfaces 

Payload 

Payload close-outs and postlanding 
operations involving direct contact with 
the payload 

Payload 
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7.1.7 KSC I&T Flow 

The general shuttle small payloads I&T flow at KSC is 
shown in figure 1 . 

7.2 Postship Operations at the PPF 

7.2.1 Responsibilities at the PPF 

Since operations at the PPF are off-line and stand-alone, 
the payload shall have the primary responsibility for 
performing this work. Generally, this includes prelaunch 
functional testing, payload preparations for orbiter 
integration, and any postflight operations prior to 
shipment back to the home facility. 

KSC personnel are responsible for providing payload 
support and resources, as defined in the LSSP and the 
PRD. 

7.2.2 Facilities 

Several KSC facilities are used as PPFs for small 
payloads, including the Multi-Payload Processing 
Facility (MPPF), Space Station Processing Facility 
(SSPF), Radioisotope Thermoelectric Generator 
Facility (RTGF), and Multi-Operations Support 


Building (MOSB). Flistorically, even off-site facilities 
(such as the SpaceHab facility and Cape Canaveral Air 
Force Station hangars) have also been used as PPFs. 
Each facility requires separate familiarization training 
for access and crane operation. 

In recent years, the MPPF has been used for shuttle 
small payloads. The relative isolation of the MPPF 
affords users a certain level of autonomy. For example, 
payload technicians can be easily trained and certified 
to operate the MPPF crane. One drawback, however, is 
that the MPPF is still considered a secure area and 
requires proper badging for access. There is also some 
level of competition from multiple payload 
organizations requiring use of the MPPF. 

If a larger facility such as the SSPF is used, several 
points should be considered. First, the payload should 
be cordoned off if it is not in a separate secure area. 
Second, only KSC technicians are qualified to operate 
the overhead bridge cranes; therefore, at least two KSC 
crane operators must support major lifts. Third, the 
proximity to KSC payload personnel helps in obtaining 
KSC support resources, yet also invites more intense 
scrutiny. Finally, office space is usually at a premium, 
so small payload representatives may be relegated to 
remote locations. 


Integration and Test at KSC 


Payload 
Processing 
Facility (PPF) 



• Receiving & inspection 

• Post-ship functional tests 

• Blanket/tape close-outs 

• Final payload assembly 
(if req'd) 

• Servicing (if req'd) 

• Sharp-edge inspection 

• Install covers & wrap (if req'd) 

• Install into transport vehicle 

• Transfer to OPF or pad 


• Install into orbiter . Shutt i e stacking 

Orbiter 1VT . T ranS p 0 rt to Pad 

• Servicing (if req'd) 

• Remove covers (if req'd) 

• Close-out photos 

• Transfer to VAB 


Canister 
Rotation 
Facility (CRF) 


• Install into orbiter (if not OPF) 

• Orbiter IVT (if not OPF) 

• Remove covers (if req'd) 

• Close-out photos (if pad ops 
performed) 

• Launch 


Mission 


• Rotate transport canister 

• Transport to Pad 


Payload 
Processing 
Facility (PPF) 


Orbiter 
Processing 
Facility (OPF) 


Shuttle Landing 


Facility (SLF) 



• Remove from transport vehicle 

• Reinstall covers (if req'd) 

• Postflight testing (if req'd) 

• Payload deintegration (if req'd) 

• Prep for ship to home facility 

• Ship 


• Remove payload from orbiter 

• Install covers & wrap (if req'd) 

• Install into transport vehicle 

• Transport to PPF 


• Landing 

• Tow t> OPF 


Figure 1. 
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7.2.3 Receiving, Inspection, and Set-up 

Following arrival at the PPF, the payload and GSE are 
off-loaded from the truck, usually in the reverse order 
from loading. Only hydraulic lift gates and forklifts may 
be used to unload flight hardware from small dollies. 
Use of truck platforms supported by chains is 
prohibited, since these have failed in the past, resulting 
in damage to GSE and potential damage to flight 
hardware. 

If an elevated truck lock is unavailable, cross-bay 
payload hardware has been off-loaded using a 
combination of flatbed truck and portable crane. The 
use of roll-backs (or “Jerr-Dans”) has more recently 
been approved by KSC safety for off-loading large 
payloads. 

As the hardware is off-loaded, the individual who 
coordinated the shipping from the home facility verifies 
all hardware has been received and signs off the bill- 
of-lading. After unloading, the flight hardware and GSE 
are usually rolled into an intermediate truck-lock area 
for unpacking and cleaning. Once inside the main clean 
room, the hardware is configured for postship testing 
and any additional integration required before transfer 
to the orbiter. 

7.2.4 Mechanical Integration 

Depending on the type of payload, off-line mechanical 
integration at the PPF can be relatively simple or very 
complex. For example, side-mounted payloads typically 
remain on dollies until orbiter integration. The price 
for this simplicity is paid during orbiter integration, 
when individual components must then be mounted and 
connected sequentially, and their electrical interfaces 
verified during the IVT. 

For larger payloads, such as cross-bay bridges, PPF 
operations may require more mechanical integration. 
There may also be some instruments that are shipped 
on dollies separately, which would then have to be 
installed at the PPF. 

7.2.5 Electrical I&T 

Once the payload is set up and connected to the EGSE, 
postship functional testing may commence. This testing 
includes activation of the carrier and all instruments, 
depending on customer support available. 


Usually, the last test performed at the PPF is a final 
IVT sim. Fike the sim performed prior to shipment, 
the test at Kennedy is based on the IVT OMI, except 
that the latest version of the KSC procedure is used. 

If the IVT involves using a PGSC, the payload 
organization (i.e., the I&T manager) is again responsible 
for obtaining a PGSC loaner from ISC. This last sim 
should be run using the latest flight software load from 
ISC, not only to verify software compatibility but to 
verify the orbiter IVT sequences with the latest OMI. 

Unfortunately, the final flight load is usually unavailable 
for the IVT sim or even the IVT itself. As mentioned 
earlier, ISC should notify the payload organization of 
any changes to the mission software to avoid surprises 
either during the IVT or on orbit. To ensure the payload- 
unique software will not be affected, there should also 
be a mutually agreed upon limit to the extent of any 
changes to the ISC flight load. 

Upon completion of electrical I&T, any customer GSE 
can be packed for shipment to the POCC if needed to 
support the mission, or left at KSC if required to support 
the IVT. 


7.3 Transfer to Orbiter 

7.3.1 Preparations for Transfer 

As mentioned earlier, a final configuration review is 
performed by a payload representative at the PPF. This 
is usually performed just prior to transfer to the orbiter. 
Although this check will have been performed just prior 
to shipment to KSC, this last-minute verification checks 
the final flight configuration following PPF operations. 

A sharp-edge inspection is usually performed by a 
representative from the Vehicle Integration Test Team 
(VITT). Any areas of concern must be addressed prior 
to payload closeout for transfer. A contamination 
inspection is also performed, with any required cleaning 
supported by payload mechanical and thermal 
technicians. In general, the cleaner the payload is prior 
to transfer to the orbiter, the cleaner it will be on orbit. 

7.3.2 Transfer from PPF 

After all off-line operations are complete, a final 
weighing of the payload is usually performed prior to 
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transfer and the data is provided to KSC. The payload 
is then either double wrapped (in the case of side- 
mounted payloads) or loaded into the transport canister 
(for cross-bay payloads). 

For lifting larger payloads, KSC’s Integrated Partial 
Payload Lifting Assembly (IPPLA) is the MGSE of 
choice since it allows for c.g. adjustment. If the IPPLA 
is used, prelift inspections of both the bridge trunnions 
and IPPLA trunnion supports are recommended to 
ensure no damage will be incurred. 

Occasionally, customers require a continuous drag-on 
purge for their instruments. Unless optional service 
accommodations are negotiated with KSC, periodic 
interruptions of the purge are usually necessary during 
orbiter transfer operations. 

7.3.3 CITE Testing 

The horizontal CITE stand is a high-fidelity orbiter 
avionics simulator located in the SSPF. The purpose of 
CITE is to verify, prior to orbiter integration, new 
payload electrical interfaces to the orbiter. 

Reusable payload carriers such as Hitchhikers are 
typically exempt from CITE testing, since electrical 
interfaces to the orbiter usually do not change from 
mission to mission. Since CITE is required by default, 
KSC conducts a “CITE bypass study” to assess whether 
the test is necessary. 

The CITE IVT procedure is basically the same as the 
orbiter IVT, and is a good dry-run for the final orbiter 
test. A CITE test typically adds about a month to the 
prelaunch flow, including transfer operations. 

7.4 Orbiter Integration 

7.4.1 I&T Responsibilities at the OIF 

KSC shall have the primary responsibility for 
integration (and deintegration) involving payload-to- 
orbiter interfaces. This task includes payload installation 
into (and removal from) the orbiter, as well as 
connection (and disconnection) of payload-to-orbiter 
interfaces. It also includes installation (but not 
connection) and removal (but not disconnection) of any 
payload-to-payload cable harnesses that must be routed 
within the payload bay structure. The payload 
organization is responsible for providing support for 
such operations, as required. 


The payload team shall be responsible for performing 
integration (and deintegration) involving payload-to- 
payload interfaces during orbiter operations. This work 
includes installation (and removal) of payload 
components, such as remove-before-flight items, drag- 
on purges, and payload-to-payload electrical 
connections. It also includes connection (and 
disconnection) of any payload-to-payload cable 
harnessing routed within the payload bay structure. KSC 
is responsible for providing support for such operations, 
such as platforms or bridge-bucket support for payload 
customer access. 

During integrated orbiter operations, KSC shall be 
responsible for performing payload testing involving 
payload-to-orbiter interfaces. This includes tests such 
as the payload-to-orbiter IVT and other integrated 
procedures involving payload activation via orbiter 
power. The payload provides test support for any 
integrated procedures requiring payload activation. 

The payload team shall be responsible for performing 
all stand-alone operations involving payload-provided 
GSE. This work includes tests such as the payload-to- 
orbiter IVT and other integrated procedures involving 
payload activation. It also includes tests involving 
payload activation via stand-alone power supplies or 
internal batteries, i.e., not requiring orbiter activation. 
KSC provides support for payload testing, as required. 

7.4.2 PGSC Operations 

As mentioned above, KSC has primary responsibility 
for performing those operations involving payload-to- 
orbiter interfaces, and the payload provider performs 
operations on payload-to-payload interfaces. There are, 
however, other tasks involving interfaces for which the 
responsible parties are less clearly defined. A case in 
point is when a payload-provided PGSC is being used 
during orbiter integrated operations. These operations 
include tests such as the payload-to-orbiter IVT and 
other procedures involving payload activation using 
orbiter power. 

Such operations involving the PGSC and payload- 
provided software are usually conducted by KSC 
personnel. However, since the payload customer 
provides any payload-unique software, and is therefore 
most familiar with its operation, a payload 
representative should monitor all PGSC operations. This 
is especially important for payloads with PGSC 
commands which, for example, initiate an irreversible 
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experiment sequence. Having an experienced payload 
representative overseeing the PGSC operations helps 
to ensure that all payload commanding is properly 
executed. 

Finally, if any flight crew support payload testing at 
KSC, they generally perform any orbiter or payload 
keyboard and switch operations. This is also a good 
opportunity for the crew to gain valuable training with 
the actual mission hardware and software in the flight 
configuration. 

7.4.3 Operations Scheduling 

Once in the orbiter flow, the payload is at the mercy of 
the orbiter integrated schedule. The I&T manager must 
remain cognizant of potential schedule impacts, 
especially those that require contiguous multishift 
operations-often a challenge for small-payload teams. 

At KSC, it is sometimes unclear who is the single-point 
contact for payload operations during orbiter 
integration: a representative from the KSC Payload 
Ground Operations Contractor (PGOC), someone from 
the Shuttle Flight Operations Contractor (SFOC), or 
the NASA payload manager. If on hand, the PGOC 
payload ops person is usually considered the single- 
point contact for scheduling payload operations. While 
at the OPF, however, the SFOC payload ops person is a 
more direct line to the orbiter world. 

Unfortunately, while quite helpful in providing support, 
payload ops personnel have little authority over 
prioritizing operations. Ultimately, it is left to the 
payload I&T manager to advocate on behalf of the 
payload for KSC support to allow payload operations 
to remain on schedule. 

To help mitigate against potential support discrepancies, 
a pretask briefing should be held with all participants 
the day prior to (not morning of) the operation. Having 
KSC complete pre-op, such as crane and access 
preparations, the day before a major task is also helpful. 

7.4.4 Contamination Control 

Contamination control during orbiter integration, 
particularly in the OPF, is somewhat less stringent than 
in the PPF. In the case of side-mounted payloads, 
staging in the relatively unclean OPF transfer isle can 
introduce contamination. Here, and even in the payload 


bay itself when payloads are not installed, KSC 
personnel are not required to wear full clean room 
garments. 

Therefore, the I&T manager should request that all 
personnel in the vicinity of the payload wear proper 
clean room attire. The LSSP and OMRSD should also 
include explicit cleanliness requirements, if applicable. 
These measures not only help mitigate risk of 
contamination, but also help instill a more diligent level 
of awareness in the handling of flight hardware. 

Also at the OPF is the risk of FOD being introduced 
inside the payload bay. This is a concern particularly 
during installation of side-mounted payloads because 
this effort typically requires frequent handling of 
fasteners and tools. Since noncaptive fasteners cannot 
be tethered, one suggestion is to install a temporary 
tarp or other FOD capture device directly below the 
hardware being installed. This precaution is especially 
important in bays where the payload bay liner has been 
removed. It also helps to have spare fasteners on hand 
so that integration can continue if a fastener is 
temporarily lost. 

Another problem encountered during installation of 
side-mounted payloads is the risk of contamination from 
fastener grease. Orbiter technicians are usually not 
required to wear gloves to install fasteners, thus 
introducing the risk of transferring grease to the 
payload. Even if gloves are worn, grease can still be 
transferred to flight surfaces if the gloves are not 
replaced after becoming soiled. 

At the pad, Payload Changeout Room (PCR) cleanliness 
is significantly better than at the OPF. The primary 
concern at the pad is debris from operations or other 
payloads situated above, as well as occasional 
incidences involving the PCR ventilation system. This 
risk can be mitigated through the use of a debris shield 
installed directly above the payload in the PCR, as 
requested via the LSSP and PRD. 

There are, however, a couple of issues associated with 
a debris shield. First, installation of the shield itself can 
increase the risk of contaminants falling onto the 
payload or the payload being accidentally contacted. 
Second, the shield is not a contiguous piece of material 
and therefore may not fully protect the payload from 
falling dust and debris. Third, the proximity of an 
adjacent payload installed above may not allow enough 
clearance for a debris shield. 
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Regardless of whether a debris shield is used or not, 
the payload should be fully inspected during pad 
closeouts and cleaned for flight, as necessary. 

7.4.5 Payload Handling Issues 

Over the years, many incidences of damage to payload 
flight hardware, particularly during orbiter integration, 
have been reported. In addition, some practices which 
have become almost standard for flight hardware 
development (e.g., use of wrist-stats and gloves) are 
not usually implemented during orbiter processing. 

Special handling requirements can be addressed in the 
LSSP, but they should also be noted in the applicable 
WAD to ensure visibility. For operations involving 
payload-to-payload interfaces, the I&T manager must 
be diligent about ensuring that only payload personnel 
execute them. 

In cases where the payload contains ordnance, everyone 
working with the hardware should be reminded that 
ESD protection is mandatory when handling the 
hardware. It is also helpful to have extra conductive 
gloves on hand during orbiter operations, since these 
are sometimes not readily available in the OIFs. 

7.4.6 Physical Interfaces 

Mechanical and electrical interfaces between the 
payload and orbiter are integrated per WADs such as 
TOs and TPSs. If the hardware does not match the 
documentation, however, some form of 
nonconformance paperwork (such as a problem report) 
is opened, and a real-time modification with follow-up 
documentation is required. 

Performing a configuration verification on the payload 
hardware, as mentioned earlier, can help avoid some 
conflicts prior to orbiter integration. For example, one 
Hitchhiker payload had a wrong keel trunnion installed, 
a problem not discovered until orbiter installation. 

One payload electrical interface that causes recurring 
difficulties is the zero-gauge Standard Mixed Cargo 
Harness (SMCH) power cable. In several instances, the 
payload-to-orbiter ICD has referenced a cable length 
or routing that was physically impossible to implement. 
Also, if the payload has any cross-bay cables (provided 
in advance to SFOC for installation), routing should be 
verified by the payload as soon as possible to ensure 


the cables can be connected properly prior to IVT. Since 
the actual routing of payload cables is difficult to define 
prior to orbiter integration, a change to the ICD is often 
required. 

7.5 Payload-to-Orbiter IVT 

7.5.1 Scope 

Strictly speaking, the orbiter IVT is limited to exercising 
only those power and signal functions required to verify 
copper path interfaces between the payload and orbiter, 
or payload-to-payload interfaces connected after orbiter 
installation. It should be noted that because side- 
mounted payloads typically involve more payload-to- 
payload mates during orbiter integration, more 
interfaces need to be verified during their IVTs. 

Since the IVT is considered a copper-path verification, 
no functional testing is usually performed. Despite this, 
occasionally some limited amount of functional testing 
is performed in conjunction with IVT. This activity may 
be acceptable if there is sufficient technical justification, 
such as a late prelaunch instrument calibration. Even if 
justifiable, scheduling and access are usually the most 
significant issues associated with functional testing. It 
should be noted that every additional payload command 
(sent via LPS) can require as many as a half-dozen 
additional OMI steps to implement, as well as additional 
bit patterns defined in PIP Annex 4. 

An alternative to performing payload functional testing 
within the context of the IVT is to conduct a stand- 
alone test independent of orbiter power. This test is 
typically performed via a payload test connector and 
external drag-on power supply. 

Regardless of the approach, all requirements for testing 
in the orbiter must be documented in the OMRSD. This 
is the means by which KSC officially acknowledges 
and allocates resources for support. 

7.5.2 Procedure Development 

The I&T manager, or designee, typically provides KSC 
with inputs required for IVT OMI development. These 
inputs are usually provided several months prior to 
delivery to KSC. Any steps performed in the OMI 
should have a corresponding OMRSD requirement that 
is ultimately fulfilled through their implementation. 


20 


Integration and Test of Shuttle Small Payloads 


Historically, some payloads have had an “IVT support 
procedure” to be run by payload support personnel, in 
conjunction with KSC’s IVT OMI. Such a procedure 
can be cumbersome, however, not only to maintain as 
procedurally consistent with the OMI, but also to run 
in parallel with the IVT. If the IVT is written accurately, 
no other support procedure should be required. Possible 
exceptions include pre- or post-ops, or those payload- 
specific operations outside the scope of the IVT itself. 

7.5.3 Scheduling 

It is most beneficial if KSC schedules the payload-to- 
orbiter IVT as soon as possible following payload 
installation and connection to the orbiter. Prompt 
completion of the IVT helps small payload teams 
minimize travel, since many of the same people who 
support installation also support IVT and subsequent 
close-outs. 

In addition, delaying the IVT a week or more beyond 
installation introduces potential risks to the overall 
schedule. One example is the IEH-1 Hitchhiker IVT 
(STS-69), which was originally scheduled about a week 
after installation into the orbiter. Unexpected 
circumstances (including roll-back due to a hurricane) 
delayed the IVT until 2 months later. 

7.5.4 Near-term Preparations 

A day or so prior to the IVT, KSC usually conducts a 
pretest briefing during which a timeline and deviation 
package are distributed. The I&T manager and any other 
payload personnel supporting the IVT should attend 
this meeting. 

During the briefing, the I&T manager should also verify 
with KSC that: 

• KSC orbiter and payload personnel supporting the 
IVT are aware of their respective responsibilities 

• If IVT is to be performed as the OPF, dedicated 
bridge bucket support (if required) will be available; 
bucket operators should be available on-station from 
pre- to post-ops, as necessary 

• All KSC equipment required to support IVT (e.g., 
MGSE, bridge bucket) is on hand and functionally 
tested no later than the day before IVT 

• Payload access platforms (if required) will be 
installed the day prior to IVT 


• Those networks required during IVT, such as OIS 
and CCTV, will be functionally tested end-to-end 
the day before IVT; if earlier, then patching could 
be inadvertently changed; if later, then systems may 
not be ready in time for the call-to-stations 

• For ordnance operations, local clear and RF-silence 
will be established at the proper point in the 
procedure. 

In addition, the payload TC should hold a separate 
pretest briefing with the payload team, usually after the 
KSC pretest briefing. This meeting typically includes 
payload-specific details such as personnel assignments 
and stations, and any customer support issues. Everyone 
supporting the IVT in the OIF should have the proper 
training and certifications, and any necessary escorts 
should be prearranged. Further, the payload team should 
be reminded of their OIS call signs, proper on-net 
etiquette, and test team discipline. 

Performing the pre-IVT survey of the payload 
(“walkdown”) on the day before (versus the day of) the 
test is also highly recommended. Early completion of 
the walkdown allows at least one shift to address any 
issues discovered. For example, in the case of 
MightySat/SAC-A Hitchhiker (STS-88), the walkdown 
was scheduled only 2 hours prior to call-to-stations. 
During the walkdown, the payload-to-orbiter interface 
cables were found to have been routed too tightly in 
the bay. Payload activation was delayed several hours 
while KSC technicians adjusted the cables. 

Finally, the I&T manager is responsible for ensuring 
that all payload-provided test equipment is available, 
such as PGSCs, scopes, meters, and any payload-unique 
GSE. In the case of the PGSC, a flight-like unit is 
boiTowed from JSC via the RFS form, as is done for 
stand-alone testing. Receiving PGSCs (from JSC) may 
need to be coordinated with the flight crew equipment 
representatives at KSC. The final flight software load 
(or as close to it as possible) should be used during the 
orbiter IVT to ensure that the payload-unique software 
operates properly during the mission. 

7.5.5 Performing the IVT 

As mentioned earlier, the same individuals who 
participated in the IVT sim should participate in the 
actual orbiter IVT. In the case of Hitchhikers, the 
payload TC is usually stationed at the PPF, where the 
carrier and customer C&DH GSE is located. This 
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proximity allows easy communication with the 
customers and viewing of telemetry and video monitors 
(if applicable). Extraneous observers should also be 
located at the PPF. 

The Hitchhiker mission manager usually supports from 
the LC-39 firing room, where the KSC PTC and 
engineers are stationed. At that location, he or she is 
able to provide any payload customer signatures 
required on any OMI deviations or problem reports. 

For orbiter aft flight deck operations, crew support is 
the first choice, if available. If a PGSC is required for 
IVT, the operator should be the payload software 
engineer when crew is unavailable. In any case, it is up 
to the payload TC to decide who is best qualified to 
operate the PGSC, with concurrence from project 
management. Of course, the operators should have all 
the training and certifications required for crew module 
access. 

Payload personnel may also be required to support from 
the payload bay. They should arrive at the OIF early 
enough to allow time to check in all test equipment and 
tools with the access monitor. As usual, any test 
equipment required to support IVT in the payload bay 
must be tetherable and secured. 

All personnel supporting the IVT should be on-station 
at least one-half hour prior to start of their pre-ops or 
call-to-stations, as applicable. The payload team should 
utilize the separate, preassigned OIS channel for any 
off-line discussions during the IVT. On-line 
communications are restricted to responses called out 
in the procedure itself, with the payload TC responding 
for the rest of the team unless otherwise specified. 
Telephones should be used for extended conversations 
or those discussions unrelated to the IVT. 

As mentioned earlier, payload test team discipline must 
be maintained, especially during the IVT which may 
involve a hundred or so KSC personnel. One notable 
situation was when most of the payload test team 
(stationed at the OPF) decided to take a dinner break in 
the middle of the IVT, without notifying the rest of the 
team. As a result, the IVT was on hold for almost an 
hour, awaiting the return of the payload personnel. In 
situations like this, the I&T manager (or test conductor) 
should remind the payload team of their' responsibilities 
to complete the test as efficiently and safely as possible. 


Upon completion of all testing, any payload GSE can 
be packed for shipment to the POCC, if required to 
support the mission. Any flight crew equipment (such 
as PGSCs) may be dispositioned by the flight crew 
representative. 

7.6 Closeouts and Launch 

7.6.1 Closeouts 

Some payload operations must be performed as late as 
possible prior to launch. This typically means no later 
than a day or so prior to final payload bay door closure 
either at the OPF or pad. Fate payload operations 
generally do not involve orbiter power; therefore, any 
testing requires stand-alone power supplies. Testing 
may include, for example, a last-minute instrument 
calibration or battery top-charge. 

Payload closeouts are those operations required to 
finally configure and verify the payload for flight, 
including 

• Removing “remove-before-flight” (or “red-tag”) 
items, such as dust covers and purge lines 

• Installing arm plugs for ordnance or other functions, 
such as enabling satellite batteries 

• Verifying armed circuits, for example, via continuity 
measurements at a test connector 

• Performing a walkdown of the payload to verify 
configuration and cleanliness, and that all nonflight 
items have been removed 

• Taking close-out photos. 

Payload closeout requirements, whether at the OPF or 
pad, must also be predefined in the OMRSD. Since these 
operations are generally performed by payload 
personnel, they are usually specified in a separate 
payload procedure. 

7.6.2 Launch 

Unless the payload is powered during launch or utilizes 
a “T-0 interface,” payload personnel are usually not 
required to support launch at KSC. Instead, payload 
representatives should be stationed at the POCC for 
payload activation. 
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The I&T manager is usually not required to support the 
mission. The I&T manager should, however, be on-call 
in case a problem develops which requires his or her 
expertise. 

8. POSTFLIGHT OPERATIONS 

8.1 At KSC 

8.1.1 Postlanding and Orbiter Deintegration 

As with launch, payload personnel are generally not 
required to support landing. Any postlanding operations 
are performed in the OPF following payload bay door 
opening. The only postlanding stand-alone operations 
for small payloads are usually dust cover reinstallations 
and safing of ordnance circuits, if necessary. A non- 
KSC landing usually does not involve secondary 
payloads unless some unique requirement has been 
prenegotiated. Again, any requirements for operations 
in the orbiter must be documented in the OMRSD. 

Electrical disconnections are performed in the OPF, 
usually in the reverse order of connection, with the same 
respective KSC and payload responsibilities noted 
earlier. Payload transfer back to the PPF is also 
performed in essentially the reverse order of prelaunch 
integration. Any payload-provided cables removed from 
the payload bay should be returned to the payload 
organization. 

8.1.2 PPF Operations 

Once the payload arrives back at the PPF, it is generally 
prepared for shipment back to the home facility. For 
Hitchhikers, no postflight activation of the payload is 
usually performed at the PPF. 

In some cases, customers request that specific postflight 
operations, such as data retrieval or even instrument 
deintegration, be performed at the PPF. It is 
recommended, however, that customer hardware be 
deintegrated after return to the home facility, unless there 
is sufficient technical justification otherwise. Performing 
work at KSC beyond the minimum required to ship the 
payload back home requires more procedures to be run 
at KSC. This approach tends to increase the time in the 
field, as well as the probability of encountering 
unforeseen problems. 

For example, following the flight of IEH-1 (STS-69), 
one customer requested that his instrument be removed 


from the payload at the PPF. Although this had not been 
the original plan, the consensus was that early 
deintegration would expedite experiment sample 
removal, as well as eliminate the need for the customer 
to travel to GSFC. Unknown to all was that one of the 
sample vials, which contained a hazardous substance, 
had broken within the canister. When the can was 
opened the noxious gas escaped, resulting in a 
hazardous situation inside a KSC facility. Fortunately, 
no one was injured, but a valuable lesson had been 
learned at a risk to human health. 


8.2 Back at the Ranch 

8.2.1 Deintegration 

Upon return to its home facility, the payload and GSE 
are off-loaded and inspected for damage. Any postflight 
troubleshooting deemed necessary should be performed 
before any hardware is deintegrated from the payload. 

As with integration, deintegration is performed in the 
most logical sequence. Removal of customer hardware 
depends on accessibility of the hardware, as well as 
availability of the customers themselves. For 
Hitchhikers, carrier hardware can remain installed if 
required to support a subsequent mission. Generally, 
however, all mission-unique hardware is removed from 
the payload and returned to storage for future use. 

8.2.2 Documentation 

Following postmission activities, the I&T manager 
should compile and distribute a summary of any 
“lessons learned.” This report should include any 
significant I&T-related issues experienced, as well as 
suggestions for improvement. Specific team members 
should also be commended for their efforts. 

In addition, the I&T manager should provide some 
comments to KSC regarding operations in the field. This 
feedback may include a KSC payload customer survey, 
an Opportunity For Improvement (OFI) form, or simply 
constructive comments to key individuals. 

Payload customers should be asked to submit some foim 
of customer survey to the payload carrier organization. 
This feedback can help the payload team gain insight 
into improving customer support and payload 
processing. The format for the customer survey used 
for Hitchhikers can be found in the CARS document 

[4]. 
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Finally, all payload documentation and logbooks 
(including as-run procedures) should be closed and 
archived to make them available for future reference. 

9. CONCLUSION 

A successful shuttle mission depends on the safe and 
efficient integration and test of the payload. This, in 
turn, depends on the diligent efforts of the I&T manager 
and I&T team. 

Although small payloads often go unrecognized, and 
are usually undervalued, these represent the most cost- 
effective means of accomplishing space missions. 
Following the guidelines and recommendations 
included in this document, I&T managers can help 
continue this legacy of safety and efficiency well into 
the new millennium. 
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ACRONYMS AND ABBREVIATIONS 

CARS Customer Accommodations and 

Requirements Specifications 
CCB Configuration Control Board 

CCCR Customer Configuration Change Request 

CCR Configuration Change Request 

CCTV Closed-Circuit Television 

C&DH Command and Data Handling 

CIR Cargo Integration Review 

CM Configuration Management 

DOT Dept, of Transportation 

EGSE Electrical Ground Support Equipment 

ELSA Emergency Life Support Apparatus 

EMC Electromagnetic Compatibility 

ESD Electrostatic Discharge 

FOD Foreign-Object Debris 

FPM Future Payload Manager 

GEVS Goddard Environmental Verification 

Specifications 

GSE Ground-Support Equipment 

GSFC Goddard Space Flight Center 

ICD Interface Control Document 

IPPLA Integrated Partial Payload Lifting 

Assembly 

I&T Integration and Test 

IVT Interface Verification Test 

JSC Johnson Space Center 

KSC Kennedy Space Center 

L Launch 

LPS Launch Processing System 

LSSP Launch Site Support Plan 

MGSE Mechanical Ground Support Equipment 

MIP Mandatory Inspection Point 

MOSB Multi- Operations Support Building 

MPESS Mission-Peculiar Equipment Support 

Structure 

MPPF Multi-Payload Processing Facility 

MSDS Material Safety Data Sheet 

NSI NASA Standard Initiator 

OFI Opportunity For Improvement 

OIF Orbiter Integration Facilities 

OIS Operational Intercommunication System 

OMI Operations and Maintenance Instructions 

OMRSD Operations and Maintenance Require- 
ments and Specifications Document 

OPF Orbiter Processing Facility 

PACAS Personnel Access Control Accountability 

System 

PCR Payload Changeout Room 


PERT 

Performance Evaluation Review 
Technique 

PGOC 

Payload Ground Operations Contractor 

PGSC 

Payload and General Support Computer 

PIP 

Payload Integration Plan 

POCC 

Payload Operations Control Center 

PPF 

Payload Processing Facility 

PPT 

Payload Processing Team 

PRD 

Program Requirements Document 

PRP 

Personnel Reliability Profile 

PSP 

Payload Signal Processor 

RFS 

Request For Support 

RTGF 

Radioisotope Thermoelectric Generator 
Facility 

SFOC 

Shuttle Flight Operations Contractor 

SMCH 

Standard Mixed Cargo Harness 

SSPF 

Space Station Processing Facility 

SSPPO 

Shuttle Small Payloads Project Office 

TAA 

Temporary Area Authorization 

TC 

Test Conductor 

TPS 

Test Preparation Sheets 

VITT 

Vehicle Integration Test Team 

WAD 

Work Authorization Document 
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